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Whereas the Parliament of India has set out to provide a practical regime of right to 
information for citizens to secure access to information under the control of public authorities, 
in order to promote transparency and accountability in the working of every public authority, 
and whereas the attached publication of the Bureau of Indian Standards is of particular interest 
to the public, particularly disadvantaged communities and those engaged in the pursuit of 
education and knowledge, the attached public safety standard is made available to promote the 
timely dissemination of this information in an accurate manner to the public. 
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FOREWORD 

This Indian Standard was adopted by the Bureau of Indian Standards, after the draft finalized by the 
Programming Languagesi Sectional Committee bad been approved by the Electronics and Telecom- 
munication Division Council. 

The guidelines laid down in this standard are for the purpose of improving the presentability of the 
software so as to facilitate comprehension and maintainability. 
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Indian Standard 



GUIDE FOR C-PROGRAMMB CODING 



1 SCOPE 

This standard lays down guidelines for the use 
of C-programming language. 

The coding guidelines are not supposed to do 
the following: 



„\ T»™.^4r; 






ming style and preference. 

b) To serve as a guideline for good 
programming. 

2 REFERENCES 

The following Indian Standard is a necessary 
adjunct to this standard: 

IS 1885 ( Part 52/Sec 15 ) : 1986 Electro- 
technical vocabulary: Part 52 Data process- 
ing, Section 15 Programming languages 

3 TERMINOLOGY 

For the purpose of this standard the terms and 
definitions covered by IS 1885 ( Part 52/ 
Sec 15 ) : 1986 shall apply. 

4 GENERAL 

The coding guidelines in this standard have 
been presented in a general format of name, 
standards/guidelines for writing the name along 
with examples followed by its justification. In 
some cases the alternatives for them are given. 

5 GUIDELINES FOR VARIABLES AND 
DATA 

5.1 Name 

iexvar — lexical rules for variables 
5.1.1 Standards 

a) All variables should be written in lower- 
case letters; 

b) Names should be distinct within first 
6 characters; 

c) All names should be declared explicitly 
and their sequence of declarations should 
be as follows: 

1. External names, 

2. Other names; and 

d) There should be only one declaration per 

source Vine, 



Example: 

char c — 1; /* For reading a character. 
*/float init — g = INITVAL; /* Initial 
value. */ 

e) Initializers of structures, unions, and 
arrays should be formatted with one row 

width then continue the row on the next 
line with the indent of the first element 
of the row. 

Example: 

static short 
[YMAX] = 



inputs - g [ XMAX | 



{ 



{ 1, 2> 3, 4, 5 } 
{6,7,8,9,10} 



}; 

int matrix 1 — g [ XLEN j [ YLEN ] = 

{ 

{ 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 
no, 120} 

{ 23, 32, 6, 435, 44, 42, 75, 43. 34, 55, 43, 
45 \ 

}; 

5.1.2 Justification 

The rules of the standard pinpoint location of 
declarations, distinguish lower-case names from 
upper- case names, increase readability and 
encourage documentation. 

5,2 Name 

varnames — choosing names. 

5,2.1 Guidelines 

a) Meaningful names for variables; constants 
and functions should be chosen. They 
should be exact and consistent through- 
out the program. 

b) Abbreviations for the names should be 
chosen with a uniform scheme. 

c) Names should not be redefined in inner 
blocks. 

d) Variables of all classes should be suffixed 
with an underscore, followed by one, two 
or three characters signifying its class as 
given below: 
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Major suffixes 
All globalvariables to be suffixed with: 

All Localvariables to be suffixed with: 
' - I' 

All filelevel variables to be suffixed with: 
' — f . 

Example: 

long min — g; /* Minimum value. */ 

long max — g; /* Maximum value. */ 

char count — 1; /* Count of input 
values. */ 

Short no. of pages — f = 0; /* Number of 
pages */ /* to be output. */ 

e) Formal parameters must be suffixed as 
following: 

All input parameters to be suffixed with: 

' — r. 

All output parameters to be suffixed with: 
' — o'. 

All input and output parameters to be 
suffixed with: * — io'. 

f) In addition to the major suffix following 
suffix is to be used after the major 
suffixes, 

All pointer variables to be suffixed with: 

All register variables to be suffixed with 
' r', 

AU static variables to be suffixed with: 

's'. 

Example: 

node — t --'nextnode — Ip == NULL; /'■' 
Pointer to */ next node. */ 

/*node — t is of type struct. '''/ 

5.2.2 Justification 

These rules help in avoiding misnomers and 
confusion among different classes of variables 
and hence maintenance is easier. 

5.3 Name 

stdtypes — standard defined types. 



5.3.1 Standards 

a) Since implementation of C types is 
dependent on hardware of machine, 
clarity regarding the type is important in 
a project. A standard set of data types 
must be used to make software portable. 
These defined types are mapped to raw 
C types of the compiler on the target 
machine. 

MAPPING: 



Standards 

Defined 

Types 


Raw Typ 


es 


Usage 


char 


char 




Text characters. 


integer 1 


char 




Signed and un- 
signed. 


integer 2 


short /iut 
whichever 
a length 
2 bytes 


has 
of 


Signed and un- 
signed numbers. 


integer 4 


long/int 
whichever 
a length 
4 bytes 


has 
of 


Signed numbers. 


real 4 


float 




Signed real numbers. 


real 8 


double 




Signed real numbers, 
(double precision). 


boolean 


char 




Boolean values 
(Oor 1) 


bits 1 


char 




Bit masks (I byte). 


bits 2 


short/ int 
whichever 
a length 
2 bytes 


has 
of 


Bit masks (2 bytes). 


bits 4 


long/int 
whichever 
a length 
4 bytes 


lias 
of 


Bit masks (4 bytes). 


void 


int 




Type of a function 
that does not 
return any value. 



It is assumed that on most machines this mapp- 
ing is appropriate. The data type void is to be 
used to declare functions that do not return any 
value. 
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5.3.2 Justfication 

Indication of size in the names of types of 
integers, reals and bits clarified their usage 
which ]?> useful during development of a large 
software as well as porting to other systems. If 
programs use raw C types they need to be 
edited extensively for porting. Since standard 
defined data types can be mapped to the raw 
types, depending on their implementation, few 
changes are enough to make the software work. 
If type 'void' is used, it is easy to check if a 
function returns any value at all. 

5,4 Name 

types — user defined types. 
5.4.1 Guidelines 

a) Use suffix " — t" for all names of defined 
types and write in lower-case letters. 

Example: 

typedef char name — t [NAMESIZE]; 
/*Name — type. ^7 

/*Node type for storing input values. */ 
type of struct 



struct *next; 
integer4 *nodeval; 
} node — t; 

5.4.2 Justification 

All names of types in a program can be easily 
distinguished from other names and it increases 
readability. 

5.5 Name 

Constants — choosing and using constants 
5.5.1 Standards 

a) Constants should not be hard-coded. 

b) Upper-case names should be used. 

Example: 

if define LINELENGTH 70 /* Line 
length. *l 

# define MAXNOOFSECTS 15 /; Maxi- 
mum number */ /* of sectors. */ 

c) should be placed at the beginning of 
file. 

d) when defining constants for array bounds 
use the number of elements rather than 
the index of the last element. 



# define BUFFSIZE 60 /- good */ 
char buff— 1 [BUFFSIZE]; /* good */ 

# define BUFFSIZE 59 /* bad */ ... 

char buff ~ 1 [BUFFSIZE + 1]; /* 
bad */ 

e) If a floating point is to be used, mention 
decimal point expHcitly in it even though 
it has an integral value. 

Example: 

# define FACTOR 12-0 /* Multiplication 
factor */ 

5.5.2 Justification 

Programs with hard-coded constants are diffi- 
cult to modify and debug. If such constant 
occurence is very high in all files, it is difficult 
to change each and every occurence. The same 
value might mean different things in different 
functions by requirement rather than choice. 
Confusion might arise at distinguishing these 
from variables. The fourth rule imposes strict 
usage of meaning of array bounds* consistently 
throughout all programs and hence easy to 
maintain. A decimal point in a floating point 
indicates its nature for readers. 

5.6 Name 

charconst — character constants. 

5.6.1 Standards 

a) Numeric values of character constants 
should not be used directly in programs. 

b) Special characters such as TAB, LEW- 
LINE, etc, should be defined as character 
constants. 

Example: 

# define TAB ' \ t' 

# define NEWLINE ' \ n' 

5.6.2 Justification 

Value of a character constant depends on the 
implementation of character set of machine. 

Example: 

Numeric value of '0' is 48 in ASGII 
character set. 

Numeric value of '0' is 240 in EBCDIC 
character set. 

5.7 Name 

casting — usage of casting 
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5.7J Standards 

Do not assume default conversions of 
C raw types. Explicit mention of casting 
is needed. 

Example: 

double sum — 1; /* Sum of two num- 
bers, */ 

short numl — 1 ; /* The first number. */ 

short num2 ^ 1 ; # /* The second num- 
ber. */ 

sum — 1 = (double) numl — 1 -f- (double) 
num2 -— 1; 

5.7.2 Justification 

Code can be easily understood. Errors can be 
easily located. 

5.8 Name 

ordereval — order of evaluation of expressions. 
5.8.1 Standards 

a) Programs should not be dependent on the 
order of evaluation of an expression, 
except as guaranteed by C for the 
following: 

exprl, exprl 

exprl? expr2 : expr3 

exprl && expr2 

exprl 1 I expr2 

In all these cases the first expression, 
exprl, is evaluated first. 

b) If specific order is required temporary 
variables should be used for evaluation of 
sub-expressions. 

c) No evaluation order should be assumed 
in arguments of a function. 

Ex ample: 

printf ("%d, %d/n", -|- -f i - 1, a[i]; 
/*Bad coding */ 

5.8.2 Justification 

Order of evaluation is implementation depen- 
dent; programs behave differently on different 
machines. The order of evaluation for assocative 
and commutative operators such as * and + 
is compiler dependent. 



Example'. 

x=f() +g(); 

In this statement either f () or g ( ) is computed 
first. 

5.9 Name 

synonyms — usage for clarity of programs. 

5.9.1 Guidelines 

a) Use following synonyms for clarity of 
programs. 

# define begin } 
4:^ define end } 

■i^ define end — if } 

# define end — for } 
4^ define end — while } 

# define end — function } 

# define then { 

4:j: define end — switch } 
i^ define record struct }^ 
4^ define endrec ) 

# define TRUE 1 

# define FALSE 

5.9.2 Justification 

Identification of body of statement, particularly 
that of control structure, is easy. These also 
reduce possible syntax errors. 

6 GUIDELINES FOR OPERATORS 

6.1 Name 

lexops — lexical rules for operators. 
6.1.1 Guidelines 

a) Primary operators = "— >" "."and *'[ ]" 
should be written with no space around 
them. 

Example-^ 

houserec — g — > room = i ^- 1; 
studentinfo — 1. grade... 
subject — g [ j — 1 ] 

b) No space should be written between func- 
tion name and its opening paranthesis. If 
an expression is enclosed by paraniheses, 
then no space should be left between 
opening paranthesis and the expression, 
and the expression and the closing 
paranthesis. 
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Example: 
convertual (inval — i, outval 



o); 



c) There should not be any space between a 
unary operator and its operand. 

Example'. 

+ finished — g — noofpoints — i 
*house — pi, &inval — g, size of 
(integer 4) 

d) The assignment operator must have a 
space around it. 



Example; 
raaxvalue 



1 = MAXVALUE; 



e) Commas should have one space after 
them. 

Example; 

getparameters (filnam — g, noofprmts — 1, 
prmtsarr — g); 

f ) Other operators should have one space on 
either side of them. 

Example: 

initval — 9 + displacement — 1 
number — 1 / MAXNOOFVALUES 

g) All relational operators should be defined 
as synonyms. 

Example: 

# define AND && 
ip define OR 1 \ 

# define BITAND & /* Bit AND */ 

6.1.2 Justification 

Readability of the programs is enhanced. 

7 GUIDELINES FOR CONTROL 
STRUCTURES 

7.1 Name 

lexctl — lexical rules for control statements. 

7.L1 Guidelines 

a) Each line which is a part of the body of 
a C control structure is indented one tab 
stop (preferably two spaces) from the 
margin of its controlling line. The same 
rule applies to function definitions, 
structure/union definitions. 

b) Each opening and closing braces should 
be on a separate line and are indented 
one tab stop from the controlling keyword 
of C. Code inside the braces should be 
indented to the same extent from them. 



Example: 

if ( a — 1 
X = y: 
else 

{ 

printf (". 



= = 1) 



); 



} 

switch (c — g) 



{ 

case a 
case b 






} 

c) A null statement appearing as the body 
of a loop must be placed in a separate 
line. 

while (a — 1 < bl) 

; /*Null statements. */ 

7.1.2 Justification 

Enhances readability of code. 

7.2 Name 

restrict- restrictions on use of control structures. 

7.2.1 Standards 

Do not use 'goto' statement in any 
function. 

7.2.2 Justification 

Readability is enhanced and maintenance ts 
easy. 

8 GUIDELINES FOR FUNCTIONS 
8.1 Name 

lexfns — lexical rules for functions. 
8.1.1 Standards 

a) Define a constant 'FUNCTION' as shown 
below. 

# define FUNCTION 

Write this constant before declaration of 
function. 
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Example: 

FUNCTION mteger4 convert (...) 

FUNCTION void getnames (...) 

b) Immediately after declaration of function 
give the following information (function 
main-coranient) about it as a comment. 

PURPOSE : 

INPUT ARGUMENTS 

OUTPUT ARGUMENTS 

RETURN VALUES : 

IMPLICIT INPUT VARIABLS : 

IMPLICIT OUTPUT VARIABLES : 

IMPLICIT INPUT AND OUTPUT 
VARIABLES 

CALLING FUNCTIONS 

CALLED FUNCTIONS 

AUTHOR 

DATE WRITTEN 

LOG OF CHANGES 

PURPOSE : Purpose of the function. It 
should be expressed in the form of 
"specific objects". 

RETURN VALUES : Value(s) returned by 
this function. 

IMPLICIT INPUT VARIABLES: All glo- 
bal variables (global to the function) that 
are used in the funciionbut arenot modifi- 
ed either explicitly (by this function) or 
implicitly (by a called function). 

IMPLICIT OUTPUT VARIABLES : All 

global variables (global to the function) 
that are used on the left hand side of an 
assignment of operator or as an actual 
parameter to a function, which is used to 
receive a value. Thus these are modified 
either explicitly (by this function) or 
implicitly (by a called function). 

IMPLICIT INPUT-OUTPUT VARIA- 
BLES : All global variables (global to the 
function) each of which is used as an 
IMPLICIT INPUT VARIABLE as well as 
an IMPLICIT OUTPUT VARIABLE. The 
order of usage is not considered. 

CALLING FUNCTIONS : Names of all 
functions that are called by the function 
under consideration. 

AUTHO_R : Name of the author and his 
present address. 



DATE WRITTEN : Date of which it is 
first written. 

LOG OF CHANGES : Information abou?: 
changes as follows: 

Name of the person: 

Date of change: 

Contents changed: 

Example: 

# typedef int integer2. */ 

# typedef long integer4. */ 

# include "./picture/secheader. inc" /* 
Common header file. */ 

# include < fcntl.h> /* File controi 
definitions. */ 

# define BLOCKSIZE 512 /* Buffer size. 
V 

# define DEBUG FALSE /* Debug 
option. */ 

# define READONLY /* Read mode of 
file. */ 

# define WRITEONLY 0666 /* Write 






■# define begin { 
# define end } 



FUNCTION void filecopy (fromfile — i, 
tofile — i) f' 



PURPOSE : 


Copies-contents of one 
file (from -file) to arte- 
ther-file (to file). 


INPUT 
ARGUMENTS 


fromfile — i, tofile — i 
/ Names of source atid 

destination files/ 


OUTPUT 
ARGUMENTS 

IMPLICIT 

INPUT 




VARIABLES : 
IMPLICIT 
OUTPUT 


' 


VARIABLES 


errstrl — g 


IMPLICIT 
INPUT 

AND OUTPUT 
VARIABLES ; 




RETURN : 
VALUES 


• 
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CONSTANTS 



CALLED 
FUNCTIONS 

CALLING 
FUNCTIONS 

AUTHOR 

DATE 
WRITTEN 

LOG OF 
CHANGES 



NULL, 4^C ANNTOPN- 
FIL :^/^ Error cons- 
tants #/ 

dispmessage, unoscreat, 
open, printf, read, 
stropy, write. 

genmf. 

X.Name. 

11/01/1986. 



*/ 



fistring fromfile — i, /* Name of the from- 
file. */ tofile — i; / Name of the to-file. 

{ 

integer4f — 1 */ File descriptor of the 
from file. "/ t — Ip; /* to-file; */ 

integer! n — 1 ; /* Number of characters 
read from the from-file. */ 

char buff — 1 [BLOCKSIZE]; /* Buffer */ 
/* Opens the from-file for reading and 
creates the to-file. */ 

if(((f _ ip _ open (fromfile i, READ- 
ONLY)) = = NULL) then 

{ 

stropy (errstrl — g, fromfile ~ i); 

dismessage (CANNTOPNFIL); /* Display 
error message. */ 

}y^Mf=v 

if (( t — Ip = creat (tofile -~ i, WRITE- 
ONLY)) = = NULL) then 

stropy (errstrl — g, tofile — i); 

dispmessage (CANNTOPNFIL). 

] /* if */ 

# if DEBUG 

printf "f - Ip, t-^lp %d %d \ n", f -Ip, 

t — Ip); 

:^ endif 

/* Read the from-file into buffer and write 
into the to-file */ 

while (n ■— 1 = read (f — Ip, buff — 1, 
BLOCKSIZE)) 



# if DEBUG 

printf C'h — 1 %d \ n", n ™ 1); 

printf ("buff — l%s/n", buff — 1): 

# endif 



} /* 



write (t — Ip, buff — 1, n 
{ /* while */ 

filecopy ( ) 



1): 



7 



c) If a comment is needed in the main 
comment, it must be enclosed with two 
slashes. 

Example: 

CONSTANTS: CANNTOPNFIL / An 
error message constant. / 

d) A comment for each local variable must 
be given 

e) The type of value returned by a function 
must be mentioned explicitly. If a function 
does not return any value declare it as of 
type "void". 

8.1.2 hmification 

The first rule allows one to search for 
functions easily in a file containing many 
functions. If a comment-header, as shown 
in the example above, is given for a function 
then it is easy to understand it even in the 
absence of the author and it is easy to maintain. 
Using the type "void" one can know if a func- 
tion returns any value just by seeing the 
function declaration rather than searching for 
"return" statements in it. 

8.2 Name 

cohesion-cohesion and meaningful functions. 

8.2.1 Standard 

Purpose of a function must be accurately sum- 
marized by a sentence in the form *A verb + 
its object(s)". 

Example: 

FUNCTION void filecopy (fromfile -i, 
tofiie — i) 



PURPOSE 



Copies — contents of 
one file (from-file) to 
another file (to-file) 



*/ 



8.2.2 Justification 

This avoids line by line reading of source code 
of a function to understand its purpose. 
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8.3 Name 

size — size of a function 

8.3.1 Guideline 

A function should not be more than a page of 
source listing. 

8.3.2 Justification 

small is beautiful. A small function is easy to 
understand and maintain. A big function can 
be split into smaller segments each of which is 
cohesive and can be implemented as a separate 
function. It is wrong impression that only 
repetitive code is to be implemented as a func- 
tion. Small functions make whole code more 
modular. 

9. GUIDELINES FOR C-FILES 

9.1 Name 

fnfilesize — size of file of function(s) 

^.1.1 Standard 

A source file should be no larger than 500 lines. 

9.1.2 Justification 

Larger files are difficult to edit and take more 
time to save file while editing and to compile. 

9.2 Name 

glbvarfile — file of global variables. 

9.2.1 Standard 

If number oif global variables is large and func- 
tions of each source file use many of them, then 
put them in a file and use include-directive to 
include in the file of main function. Similarly, 
put the corresponding external declarations in a 
file and use include-directive to include them in 
all the other files. 

9.2.2 Justification 

9.3 Name 

syconstfile — file of all symbolic constants. 

9.3.1 Standard 

If any symbolic constants are used in more than 
one source file, then define them in a file and 
use include-directive to include in required files. 

9.3.2 Justification 

It may happen that two programmers developing 
separate modules might use same symbolic 
constant with different values. While integrating 
program may behave unexpectedly because of 
this re-definition of the same constant. Also, if 
the same symbolic constant is defined in two 



different files for the same purpose, when a 
change of the constant value is required, all 
files are to be searched for the definition of the 
symbolic constant. In this case, the purpose 
of the symbolic constant is lost. This can be 
checked easily if all constants are in one file. 
Thus debugging and maintenance become easy. 

9.4 Name 

enumfile — file of enumerations, 

9,4.1 Standard 

If any enumeration constants are used in more 
than one file define all enumeration constants 
in one file. 

Example: 

/* Enumerations for colors */ 

# define RED 

# define GREEN 1 

# define BLUE 2 



9.4.2 Justification 

This allows to refer to these constants easily. 
Possible bugs such as using enumeration cons- 
tant as normal constant can be easily detected. 

9.5 Name 

synfile — file of synonyms. 

9.5.1 Standard 

If any synonomsBre used in more than one file, 
then define all synonyms in one file. 

9.5.2 Justification 

Locating and maintenance of these synonyms 
are easy. 

9.6 Name 

typfile — file user defined types. 

9.6.1 Standard 

Define ail types in one file. 

Example: 

typedef char filename — t (FILNAMSIZ); /* 
File name */ File name ^l /* type. */ 

typedef integer 1 color — t; /* Color type. */ 

9.6.2 Justification 

Common types can be standardised for a 
project. If they are in a separate file they can 
be shared comfortably. 



8 
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10 GUIDELINES IN GENERAL 

10.1 Name 

eaviron — environmental features. 

10.1.1 Standard 

Segregate environment spscific code into speci- 
fic small functions. 

Example: 

drive — g = "/user/catalong" /* */ 

getdrivename (drive — g); /* Good — 
dependence is */ /* in small function. */ 

10.1.2 Justification 

Minimizes and eases the work in porting soft- 
ware to a new environment. 

10.2 Name 

macros — writing macros. 
10,2.1 Standards 

a) Macros should be upper-case names. 
Example; 



10.3.1 Guidelines 

a) Each function must be documented by a 
header-comments as described in the 
chapter dealing with functions. 

b) Each paragraph or logical grouping of 
statements should be commented before 
it, indented one tab space away from the 
starting level of statements. This 
comment should be preceded by atleast 
one blank line. 

c) If a statement needs clarification, 
comment should be placed one tab space 
away from the statement. 

10.3.2 Justification 

A good document function can be easily under- 
stood without the help of its author. 

10.4 Name 

Closcfiles — closing of files. 

10.4.1 Standard 

Do not use default for closing files. Close files 
explicitly. 



MAX (X, y) /* Gives maximum of x and y 10.4,2 Justification 



I 
ABS (x) /* Gives absolute value of x */ 

b) Put parantheses around each of the 
parameters in the replacement text, and 
around the entire replacement-text. 

Example: 

# define SQUARE (x) ((x) '* (x)) /* 
Square of x */ 

10.2.2 Justification 

Macros and (library) function calls can be easily 
distinguished if macro names are written in 
upper-case letters. Problems with precedence 
and side-effects can be avoided using parantheses. 

10.3 Name 

comments — use of comments 



Some problems related to integration of modu- 
les involving files can be avoided. 

10.5 Name 

compilers — compiler features. 

10.5.1 Standard 

Programs should avoid using compilerde-pendent 
features. 

10.5.2 Justification 
Enhances portability. 

10.5.3 Alternatives 

If compiler dependent features are used, method 
for portmg the programs to other machines 
must be devised. 
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Review of Indian Standards 
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